[FEATURE] Folder and File Action Keywords #4093
Conversation
|
🥷 Code experts: Jack251970, VictoriousRaptor Jack251970, VictoriousRaptor have most 👩💻 activity in the files. See details
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame: ✨ Comment |
|
Be a legend 🏆 by adding a before and after screenshot of the changes you made, especially if they are around UI/UX. |
|
|
Warning Rate limit exceeded@01Dri has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 25 minutes and 55 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (1)
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. 📝 WalkthroughWalkthroughAdds folder- and file-search action keywords to the Explorer plugin: new English localization strings, Settings API additions to manage two new keywords and enable flags, SettingsViewModel UI entries, and SearchManager refactored to route and filter results by active action keywords. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant VM as SettingsViewModel
participant Settings
participant SM as SearchManager
participant QA as QuickAccessEngine
participant SE as SearchEngines
participant UI as ResultsDisplay
User->>VM: Update folder/file action keywords & enable toggles
VM->>Settings: Set keywords & enabled flags
Settings->>Settings: Persist config
User->>SM: Submit query
SM->>Settings: GetActiveActionKeywords(query)
Settings-->>SM: enabledActionKeywords
SM->>SM: Compute activeActionKeywords, isPathSearch
alt PathSearch (folder) active
SM->>SE: Run path-oriented search engines
SE-->>SM: pathResults
SM->>QA: GetQuickAccessResultsFilteredByActionKeyword
QA-->>SM: qaPathResults
SM->>SM: Merge (qaPathResults + filtered pathResults)
else FileSearch active
SM->>SE: Run file-oriented search engines
SE-->>SM: fileResults
SM->>QA: GetQuickAccessResultsFilteredByActionKeyword
QA-->>SM: qaFileResults
SM->>SM: Filter out path-only results, Merge (qaFileResults + filtered fileResults)
else General / QuickAccess
SM->>SE: Run default engines
SE-->>SM: results
SM->>QA: GetQuickAccessResultsFilteredByActionKeyword
QA-->>SM: qaResults
SM->>SM: Merge (qaResults + results)
end
SM->>UI: Return final filtered/merged results
UI-->>User: Display results
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes
Possibly related PRs
Suggested reviewers
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
Plugins/Flow.Launcher.Plugin.Explorer/Languages/en.xaml(2 hunks)Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs(4 hunks)Plugins/Flow.Launcher.Plugin.Explorer/Settings.cs(7 hunks)Plugins/Flow.Launcher.Plugin.Explorer/ViewModels/SettingsViewModel.cs(2 hunks)Plugins/Flow.Launcher.Plugin.Explorer/Views/ExplorerSettings.xaml(2 hunks)
🧰 Additional context used
🧠 Learnings (14)
📓 Common learnings
Learnt from: Koisu-unavailable
Repo: Flow-Launcher/Flow.Launcher PR: 3770
File: Flow.Launcher/ViewModel/MainViewModel.cs:0-0
Timestamp: 2025-06-24T19:06:48.344Z
Learning: In Flow.Launcher's Explorer plugin results, the SubTitle property always contains the directory containing the file. For file results, Title contains the filename and SubTitle contains the parent directory. For directory results, SubTitle contains the directory path itself.
📚 Learning: 2025-09-05T11:56:27.267Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3593
File: Flow.Launcher/HotkeyControlDialog.xaml:6-6
Timestamp: 2025-09-05T11:56:27.267Z
Learning: In Flow.Launcher's migration to iNKORE.UI.WPF.Modern UI framework, dialog resource keys like PopuBGColor, PopupButtonAreaBGColor, PopupButtonAreaBorderColor, and PopupTextColor are provided by the iNKORE.UI.WPF.Modern framework itself, not defined locally in the codebase theme files.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Languages/en.xaml
📚 Learning: 2025-07-01T05:46:13.251Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3791
File: Flow.Launcher.Core/Plugin/PluginManager.cs:293-295
Timestamp: 2025-07-01T05:46:13.251Z
Learning: In Flow.Launcher.Core/Plugin/PluginManager.cs, when checking if a plugin is modified within the PluginManager class itself, prefer using the internal static PluginModified(string id) method directly rather than going through API.PluginModified() for better performance and architectural design.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.csPlugins/Flow.Launcher.Plugin.Explorer/Settings.cs
📚 Learning: 2025-10-16T10:48:30.573Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3854
File: Flow.Launcher/App.xaml.cs:252-275
Timestamp: 2025-10-16T10:48:30.573Z
Learning: In Flow Launcher's App.xaml.cs, the plugin initialization block (lines 252-275) that includes PreStartPluginExecutablePathUpdate, PluginManager.LoadPlugins, PluginManager.InitializePluginsAsync, _mainVM.QueryResults(), and API.SaveAppAllSettings() does not require additional Task.Run wrappers or Dispatcher.InvokeAsync calls according to maintainer Jack251970, as the threading model is already safe as designed.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.csPlugins/Flow.Launcher.Plugin.Explorer/Settings.cs
📚 Learning: 2025-07-21T09:19:49.684Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3854
File: Flow.Launcher/App.xaml.cs:246-262
Timestamp: 2025-07-21T09:19:49.684Z
Learning: In Flow Launcher's App.xaml.cs, the asynchronous plugin initialization task (containing AbstractPluginEnvironment.PreStartPluginExecutablePathUpdate, PluginManager.LoadPlugins, PluginManager.InitializePluginsAsync, and AutoPluginUpdates) does not require additional try-catch error handling according to maintainer Jack251970, as these operations are designed to handle exceptions internally.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.csPlugins/Flow.Launcher.Plugin.Explorer/Settings.cs
📚 Learning: 2025-06-24T19:06:48.344Z
Learnt from: Koisu-unavailable
Repo: Flow-Launcher/Flow.Launcher PR: 3770
File: Flow.Launcher/ViewModel/MainViewModel.cs:0-0
Timestamp: 2025-06-24T19:06:48.344Z
Learning: In Flow.Launcher's Explorer plugin results, the SubTitle property always contains the directory containing the file. For file results, Title contains the filename and SubTitle contains the parent directory. For directory results, SubTitle contains the directory path itself.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.csPlugins/Flow.Launcher.Plugin.Explorer/Settings.cs
📚 Learning: 2025-07-21T09:19:19.012Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3854
File: Flow.Launcher.Core/Plugin/PluginManager.cs:280-292
Timestamp: 2025-07-21T09:19:19.012Z
Learning: In Flow Launcher's PluginManager.cs, the post-initialization operations (RegisterResultsUpdatedEvent, UpdatePluginMetadataTranslation, RegisterPluginActionKeywords, DialogJump.InitializeDialogJumpPlugin, and AddPluginToLists) are designed to be exception-safe and do not require additional try-catch error handling according to the maintainer Jack251970.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.csPlugins/Flow.Launcher.Plugin.Explorer/Settings.cs
📚 Learning: 2024-11-03T07:40:11.014Z
Learnt from: Yusyuriv
Repo: Flow-Launcher/Flow.Launcher PR: 3057
File: Flow.Launcher.Core/Plugin/JsonRPCPluginSettings.cs:0-0
Timestamp: 2024-11-03T07:40:11.014Z
Learning: In Flow Launcher, when using Windows Forms dialogs (e.g., in `JsonRPCPluginSettings.cs`), path validation is enabled by default in `OpenFileDialog` and `FolderBrowserDialog`, preventing users from selecting invalid paths, but it's possible to opt out of this validation on individual dialogs.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.csPlugins/Flow.Launcher.Plugin.Explorer/Settings.cs
📚 Learning: 2025-10-16T09:29:19.653Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3854
File: Flow.Launcher.Core/Plugin/PluginManager.cs:519-523
Timestamp: 2025-10-16T09:29:19.653Z
Learning: In Flow Launcher's PluginManager.cs QueryDialogJumpForPluginAsync method, when a DialogJump plugin is still initializing, returning null is intentional behavior. This allows the query to fall through to the default Explorer plugin, which serves as a fallback handler. This is different from QueryForPluginAsync and QueryHomeForPluginAsync, which show "still initializing" messages because they don't have fallback mechanisms.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.csPlugins/Flow.Launcher.Plugin.Explorer/Settings.cs
📚 Learning: 2025-09-04T11:52:29.096Z
Learnt from: jjw24
Repo: Flow-Launcher/Flow.Launcher PR: 3932
File: Flow.Launcher.Core/ExternalPlugins/PluginsManifest.cs:48-55
Timestamp: 2025-09-04T11:52:29.096Z
Learning: In Flow Launcher's PluginsManifest.cs, when dealing with version parsing for the MinimumAppVersion feature, maintainer jjw24 prefers to keep the solution simple rather than implementing comprehensive helper methods for SemVer parsing normalization.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.csPlugins/Flow.Launcher.Plugin.Explorer/Settings.cs
📚 Learning: 2025-09-13T06:04:26.977Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3593
File: Plugins/Flow.Launcher.Plugin.WebSearch/SettingsControl.xaml.cs:143-165
Timestamp: 2025-09-13T06:04:26.977Z
Learning: In Plugins/Flow.Launcher.Plugin.WebSearch/SettingsControl.xaml, the ListView_SizeChanged handler in the C# file assumes 5 GridViewColumns but the XAML may have more columns. The user Jack251970 indicated this mismatch doesn't need to be fixed when pointed out during PR #3593 review.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Views/ExplorerSettings.xamlPlugins/Flow.Launcher.Plugin.Explorer/ViewModels/SettingsViewModel.cs
📚 Learning: 2025-09-11T08:30:29.487Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3593
File: Flow.Launcher/SettingPages/Views/SettingsPaneTheme.xaml:0-0
Timestamp: 2025-09-11T08:30:29.487Z
Learning: In Flow.Launcher's SettingsPaneTheme.xaml theme editor panel, the inner ui:ScrollViewerEx within the Border (Grid.Column="1") is intentionally kept because its height cannot be expanded to the whole page due to layout constraints. This serves a different scrolling purpose than the outer ScrollViewerEx and is necessary for the theme editor panel functionality.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Views/ExplorerSettings.xaml
📚 Learning: 2025-03-28T21:20:54.978Z
Learnt from: onesounds
Repo: Flow-Launcher/Flow.Launcher PR: 3394
File: Flow.Launcher/Themes/Darker Glass.xaml:134-141
Timestamp: 2025-03-28T21:20:54.978Z
Learning: In WPF applications like Flow.Launcher, Border elements cannot directly display text content and require a child element like TextBlock to handle text rendering. This separation of concerns (Border for visual container styling, TextBlock for text display) follows WPF best practices and provides greater styling flexibility.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Views/ExplorerSettings.xaml
📚 Learning: 2025-07-06T12:21:37.947Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3572
File: Flow.Launcher/App.xaml.cs:214-216
Timestamp: 2025-07-06T12:21:37.947Z
Learning: In Flow Launcher, the UpdatePluginManifestAsync method in PluginsManifest.cs already has comprehensive internal try-catch handling that logs exceptions and returns false on failure rather than throwing, making external try-catch wrappers unnecessary.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Settings.cs
🧬 Code graph analysis (2)
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs (4)
Plugins/Flow.Launcher.Plugin.Explorer/Settings.cs (2)
Settings(14-242)ActionKeyword(229-240)Flow.Launcher.Plugin/SharedCommands/FilesFolders.cs (1)
IsLocationPathString(246-265)Plugins/Flow.Launcher.Plugin.Explorer/Search/EnvironmentVariables.cs (3)
EnvironmentVariables(10-109)IsEnvironmentVariableSearch(25-31)HasEnvironmentVar(33-41)Plugins/Flow.Launcher.Plugin.Explorer/Search/QuickAccessLinks/QuickAccess.cs (3)
List(11-28)List(30-40)QuickAccess(7-41)
Plugins/Flow.Launcher.Plugin.Explorer/ViewModels/SettingsViewModel.cs (1)
Plugins/Flow.Launcher.Plugin.Explorer/Settings.cs (2)
Settings(14-242)ActionKeyword(229-240)
🪛 GitHub Check: Check Spelling
Plugins/Flow.Launcher.Plugin.Explorer/Views/ExplorerSettings.xaml
[warning] 690-690:
quickaccess is not a recognized word. (unrecognized-spelling)
Plugins/Flow.Launcher.Plugin.Explorer/ViewModels/SettingsViewModel.cs
[warning] 282-282:
actionkeywordview is not a recognized word. (unrecognized-spelling)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
There was a problem hiding this comment.
Pull Request Overview
This PR adds two new action keywords for folder-only and file-only search functionality, along with an option to exclude Quick Access results from appearing when other action keywords are used. The changes enable more targeted search experiences within the Explorer plugin.
Key changes:
- Added FolderSearchActionKeyword and FileSearchActionKeyword to the ActionKeyword enum with associated settings
- Implemented filtering logic in SearchManager to skip results based on active action keyword type
- Added UI checkbox to control Quick Access result merging behavior
Reviewed Changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
| Settings.cs | Adds new action keyword properties and enum values for folder/file search, implements GetActiveActionKeyword method, reorganizes using statements |
| SearchManager.cs | Refactors search logic to use GetActiveActionKeyword, adds filtering for folder/file-only searches, reorganizes using statements |
| SettingsViewModel.cs | Adds new action keywords to UI model initialization, has trailing whitespace on one line |
| ExplorerSettings.xaml | Adds checkbox for Quick Access exclusion option, adjusts grid layout with improper indentation |
| en.xaml | Adds localization strings for new action keywords and checkbox |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Plugins/Flow.Launcher.Plugin.Explorer/Views/ExplorerSettings.xaml
Outdated
Show resolved
Hide resolved
Plugins/Flow.Launcher.Plugin.Explorer/ViewModels/SettingsViewModel.cs
Outdated
Show resolved
Hide resolved
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Copilot <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs (1)
283-294: Quick Access entries still bypass folder/file filtersThis helper adds every Quick Access hit even when
activeActionKeywordisFolderSearchActionKeywordorFileSearchActionKeyword, so folders leak into file-only queries and vice versa. That defeats the new per-type filtering and matches the earlier unresolved feedback. Please run each Quick Access result through the sameShouldSkiplogic (or pre-filter the collection) before unioning so action keywords remain authoritative.You can reuse
ShouldSkip:- var quickAccessMatched = QuickAccess.AccessLinkListMatched(query, Settings.QuickAccessLinks); - if (quickAccessMatched != null && quickAccessMatched.Count > 0) results.UnionWith(quickAccessMatched); + var quickAccessMatched = QuickAccess.AccessLinkListMatched(query, Settings.QuickAccessLinks); + if (quickAccessMatched is { Count: > 0 }) + { + foreach (var qa in quickAccessMatched.Where(r => + !ShouldSkip(activeActionKeyword!.Value, (SearchResult)r.ContextData))) + { + results.Add(qa); + } + }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs(10 hunks)Plugins/Flow.Launcher.Plugin.Explorer/Settings.cs(7 hunks)
🧰 Additional context used
🧠 Learnings (10)
📚 Learning: 2025-10-16T10:48:30.573Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3854
File: Flow.Launcher/App.xaml.cs:252-275
Timestamp: 2025-10-16T10:48:30.573Z
Learning: In Flow Launcher's App.xaml.cs, the plugin initialization block (lines 252-275) that includes PreStartPluginExecutablePathUpdate, PluginManager.LoadPlugins, PluginManager.InitializePluginsAsync, _mainVM.QueryResults(), and API.SaveAppAllSettings() does not require additional Task.Run wrappers or Dispatcher.InvokeAsync calls according to maintainer Jack251970, as the threading model is already safe as designed.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Settings.csPlugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs
📚 Learning: 2025-07-21T09:19:19.012Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3854
File: Flow.Launcher.Core/Plugin/PluginManager.cs:280-292
Timestamp: 2025-07-21T09:19:19.012Z
Learning: In Flow Launcher's PluginManager.cs, the post-initialization operations (RegisterResultsUpdatedEvent, UpdatePluginMetadataTranslation, RegisterPluginActionKeywords, DialogJump.InitializeDialogJumpPlugin, and AddPluginToLists) are designed to be exception-safe and do not require additional try-catch error handling according to the maintainer Jack251970.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Settings.csPlugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs
📚 Learning: 2025-10-16T09:29:19.653Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3854
File: Flow.Launcher.Core/Plugin/PluginManager.cs:519-523
Timestamp: 2025-10-16T09:29:19.653Z
Learning: In Flow Launcher's PluginManager.cs QueryDialogJumpForPluginAsync method, when a DialogJump plugin is still initializing, returning null is intentional behavior. This allows the query to fall through to the default Explorer plugin, which serves as a fallback handler. This is different from QueryForPluginAsync and QueryHomeForPluginAsync, which show "still initializing" messages because they don't have fallback mechanisms.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Settings.csPlugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs
📚 Learning: 2025-07-21T09:19:49.684Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3854
File: Flow.Launcher/App.xaml.cs:246-262
Timestamp: 2025-07-21T09:19:49.684Z
Learning: In Flow Launcher's App.xaml.cs, the asynchronous plugin initialization task (containing AbstractPluginEnvironment.PreStartPluginExecutablePathUpdate, PluginManager.LoadPlugins, PluginManager.InitializePluginsAsync, and AutoPluginUpdates) does not require additional try-catch error handling according to maintainer Jack251970, as these operations are designed to handle exceptions internally.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Settings.csPlugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs
📚 Learning: 2025-09-04T11:52:29.096Z
Learnt from: jjw24
Repo: Flow-Launcher/Flow.Launcher PR: 3932
File: Flow.Launcher.Core/ExternalPlugins/PluginsManifest.cs:48-55
Timestamp: 2025-09-04T11:52:29.096Z
Learning: In Flow Launcher's PluginsManifest.cs, when dealing with version parsing for the MinimumAppVersion feature, maintainer jjw24 prefers to keep the solution simple rather than implementing comprehensive helper methods for SemVer parsing normalization.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Settings.cs
📚 Learning: 2025-07-06T12:21:37.947Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3572
File: Flow.Launcher/App.xaml.cs:214-216
Timestamp: 2025-07-06T12:21:37.947Z
Learning: In Flow Launcher, the UpdatePluginManifestAsync method in PluginsManifest.cs already has comprehensive internal try-catch handling that logs exceptions and returns false on failure rather than throwing, making external try-catch wrappers unnecessary.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Settings.cs
📚 Learning: 2025-07-01T05:46:13.251Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3791
File: Flow.Launcher.Core/Plugin/PluginManager.cs:293-295
Timestamp: 2025-07-01T05:46:13.251Z
Learning: In Flow.Launcher.Core/Plugin/PluginManager.cs, when checking if a plugin is modified within the PluginManager class itself, prefer using the internal static PluginModified(string id) method directly rather than going through API.PluginModified() for better performance and architectural design.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Settings.csPlugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs
📚 Learning: 2025-06-24T19:06:48.344Z
Learnt from: Koisu-unavailable
Repo: Flow-Launcher/Flow.Launcher PR: 3770
File: Flow.Launcher/ViewModel/MainViewModel.cs:0-0
Timestamp: 2025-06-24T19:06:48.344Z
Learning: In Flow.Launcher's Explorer plugin results, the SubTitle property always contains the directory containing the file. For file results, Title contains the filename and SubTitle contains the parent directory. For directory results, SubTitle contains the directory path itself.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Settings.csPlugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs
📚 Learning: 2024-11-03T07:40:11.014Z
Learnt from: Yusyuriv
Repo: Flow-Launcher/Flow.Launcher PR: 3057
File: Flow.Launcher.Core/Plugin/JsonRPCPluginSettings.cs:0-0
Timestamp: 2024-11-03T07:40:11.014Z
Learning: In Flow Launcher, when using Windows Forms dialogs (e.g., in `JsonRPCPluginSettings.cs`), path validation is enabled by default in `OpenFileDialog` and `FolderBrowserDialog`, preventing users from selecting invalid paths, but it's possible to opt out of this validation on individual dialogs.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Settings.csPlugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs
📚 Learning: 2025-11-06T12:57:11.574Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 4072
File: Plugins/Flow.Launcher.Plugin.Program/Main.cs:100-111
Timestamp: 2025-11-06T12:57:11.574Z
Learning: In Flow Launcher's Program plugin Main.cs QueryAsync method, the semaphore pattern where WaitAsync(token) is inside a try-catch that only catches OperationCanceledException, followed by an explicit Release() call after the try-catch block, is safe and doesn't cause semaphore leaks. When WaitAsync throws OperationCanceledException, the semaphore is not acquired, so no release is needed. When WaitAsync succeeds, the Release() call after the try-catch executes normally.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs
🧬 Code graph analysis (1)
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs (5)
Plugins/Flow.Launcher.Plugin.Explorer/Settings.cs (2)
Settings(14-240)ActionKeyword(228-239)Plugins/Flow.Launcher.Plugin.Explorer/Search/EnvironmentVariables.cs (3)
EnvironmentVariables(10-109)IsEnvironmentVariableSearch(25-31)HasEnvironmentVar(33-41)Plugins/Flow.Launcher.Plugin.Explorer/Search/QuickAccessLinks/QuickAccess.cs (3)
QuickAccess(7-41)List(11-28)List(30-40)Plugins/Flow.Launcher.Plugin.Explorer/Search/ResultManager.cs (8)
ResultManager(16-412)Result(62-72)Result(95-173)Result(175-178)Result(180-183)Result(185-227)Result(257-283)Result(285-343)Plugins/Flow.Launcher.Plugin.Explorer/Main.cs (2)
List(54-57)Main(18-131)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
|
@jjw24 It works well for me generally. But I am not particularly sure about the refactoring within the |
|
Yeah no worries I will take a look too. |
jjw24
left a comment
jjw24
left a comment
There was a problem hiding this comment.
Just doing some initial testing, I am getting this with the file/folder action keyword when no query is inputted:
jjw24
left a comment
jjw24
left a comment
There was a problem hiding this comment.
Searching with actual path should still be triggered with a general search:
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs (1)
290-301: Quick Access results still bypass action keyword filtering.This is the same critical issue flagged in the previous review:
AccessLinkListMatchedat line 299 returns all matching Quick Access entries regardless ofactiveActionKeyword. WhenFolderSearchActionKeywordis active, Quick Access files are incorrectly included; whenFileSearchActionKeywordis active, Quick Access folders leak through. This contradicts the PR's goal of respecting action keyword scopes.Apply the previously suggested fix to filter Quick Access by type:
- var quickAccessMatched = QuickAccess.AccessLinkListMatched(query, Settings.QuickAccessLinks); + IEnumerable<AccessLink> quickAccessLinks = Settings.QuickAccessLinks; + + if (activeActionKeyword == ActionKeyword.FolderSearchActionKeyword) + quickAccessLinks = quickAccessLinks.Where(link => link.Type != ResultType.File); + else if (activeActionKeyword == ActionKeyword.FileSearchActionKeyword) + quickAccessLinks = quickAccessLinks.Where(link => link.Type == ResultType.File); + + var quickAccessMatched = QuickAccess.AccessLinkListMatched(query, quickAccessLinks); if (quickAccessMatched != null && quickAccessMatched.Count > 0) results.UnionWith(quickAccessMatched);Minor style note: The if conditions at lines 292-294 can be combined into a single expression as suggested by Copilot:
- if (activeActionKeyword != null - && activeActionKeyword != ActionKeyword.QuickAccessActionKeyword - && Settings.ExcludeQuickAccessFromActionKeywords) + if (activeActionKeyword != null + && activeActionKeyword != ActionKeyword.QuickAccessActionKeyword + && Settings.ExcludeQuickAccessFromActionKeywords)(Though the current formatting is acceptable.)
🧹 Nitpick comments (1)
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs (1)
86-110: Consider refactoring to if-else for clarity.The switch-on-boolean pattern is unconventional and less readable than an if-else chain. While functionally correct, standard conditional branching would improve maintainability.
Consider this refactor:
- switch (activeActionKeyword.Equals(ActionKeyword.PathSearchActionKeyword)) - { - case true: - results.UnionWith(await PathSearchAsync(query, token).ConfigureAwait(false)); - return [.. results]; - - case false - // Intentionally require enabling of Everything's content search due to its slowness - when activeActionKeyword.Equals(ActionKeyword.FileContentSearchActionKeyword): - if (Settings.ContentIndexProvider is EverythingSearchManager && !Settings.EnableEverythingContentSearch) - return EverythingContentSearchResult(query); - - searchResults = Settings.ContentIndexProvider.ContentSearchAsync("", query.Search, token); - engineName = Enum.GetName(Settings.ContentSearchEngine); - break; - - case false - when activeActionKeyword.Equals(ActionKeyword.QuickAccessActionKeyword): - return QuickAccess.AccessLinkListMatched(query, Settings.QuickAccessLinks); - - default: - searchResults = Settings.IndexProvider.SearchAsync(query.Search, token); - engineName = Enum.GetName(Settings.IndexSearchEngine); - break; - } + if (activeActionKeyword.Equals(ActionKeyword.PathSearchActionKeyword)) + { + results.UnionWith(await PathSearchAsync(query, token).ConfigureAwait(false)); + return [.. results]; + } + + if (activeActionKeyword.Equals(ActionKeyword.FileContentSearchActionKeyword)) + { + // Intentionally require enabling of Everything's content search due to its slowness + if (Settings.ContentIndexProvider is EverythingSearchManager && !Settings.EnableEverythingContentSearch) + return EverythingContentSearchResult(query); + + searchResults = Settings.ContentIndexProvider.ContentSearchAsync("", query.Search, token); + engineName = Enum.GetName(Settings.ContentSearchEngine); + } + else if (activeActionKeyword.Equals(ActionKeyword.QuickAccessActionKeyword)) + { + return QuickAccess.AccessLinkListMatched(query, Settings.QuickAccessLinks); + } + else + { + searchResults = Settings.IndexProvider.SearchAsync(query.Search, token); + engineName = Enum.GetName(Settings.IndexSearchEngine); + }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs(10 hunks)
🧰 Additional context used
🧠 Learnings (8)
📚 Learning: 2025-07-21T09:19:19.012Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3854
File: Flow.Launcher.Core/Plugin/PluginManager.cs:280-292
Timestamp: 2025-07-21T09:19:19.012Z
Learning: In Flow Launcher's PluginManager.cs, the post-initialization operations (RegisterResultsUpdatedEvent, UpdatePluginMetadataTranslation, RegisterPluginActionKeywords, DialogJump.InitializeDialogJumpPlugin, and AddPluginToLists) are designed to be exception-safe and do not require additional try-catch error handling according to the maintainer Jack251970.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs
📚 Learning: 2025-07-01T05:46:13.251Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3791
File: Flow.Launcher.Core/Plugin/PluginManager.cs:293-295
Timestamp: 2025-07-01T05:46:13.251Z
Learning: In Flow.Launcher.Core/Plugin/PluginManager.cs, when checking if a plugin is modified within the PluginManager class itself, prefer using the internal static PluginModified(string id) method directly rather than going through API.PluginModified() for better performance and architectural design.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs
📚 Learning: 2025-10-16T10:48:30.573Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3854
File: Flow.Launcher/App.xaml.cs:252-275
Timestamp: 2025-10-16T10:48:30.573Z
Learning: In Flow Launcher's App.xaml.cs, the plugin initialization block (lines 252-275) that includes PreStartPluginExecutablePathUpdate, PluginManager.LoadPlugins, PluginManager.InitializePluginsAsync, _mainVM.QueryResults(), and API.SaveAppAllSettings() does not require additional Task.Run wrappers or Dispatcher.InvokeAsync calls according to maintainer Jack251970, as the threading model is already safe as designed.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs
📚 Learning: 2025-07-21T09:19:49.684Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3854
File: Flow.Launcher/App.xaml.cs:246-262
Timestamp: 2025-07-21T09:19:49.684Z
Learning: In Flow Launcher's App.xaml.cs, the asynchronous plugin initialization task (containing AbstractPluginEnvironment.PreStartPluginExecutablePathUpdate, PluginManager.LoadPlugins, PluginManager.InitializePluginsAsync, and AutoPluginUpdates) does not require additional try-catch error handling according to maintainer Jack251970, as these operations are designed to handle exceptions internally.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs
📚 Learning: 2025-06-24T19:06:48.344Z
Learnt from: Koisu-unavailable
Repo: Flow-Launcher/Flow.Launcher PR: 3770
File: Flow.Launcher/ViewModel/MainViewModel.cs:0-0
Timestamp: 2025-06-24T19:06:48.344Z
Learning: In Flow.Launcher's Explorer plugin results, the SubTitle property always contains the directory containing the file. For file results, Title contains the filename and SubTitle contains the parent directory. For directory results, SubTitle contains the directory path itself.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs
📚 Learning: 2025-10-16T09:29:19.653Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3854
File: Flow.Launcher.Core/Plugin/PluginManager.cs:519-523
Timestamp: 2025-10-16T09:29:19.653Z
Learning: In Flow Launcher's PluginManager.cs QueryDialogJumpForPluginAsync method, when a DialogJump plugin is still initializing, returning null is intentional behavior. This allows the query to fall through to the default Explorer plugin, which serves as a fallback handler. This is different from QueryForPluginAsync and QueryHomeForPluginAsync, which show "still initializing" messages because they don't have fallback mechanisms.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs
📚 Learning: 2024-11-03T07:40:11.014Z
Learnt from: Yusyuriv
Repo: Flow-Launcher/Flow.Launcher PR: 3057
File: Flow.Launcher.Core/Plugin/JsonRPCPluginSettings.cs:0-0
Timestamp: 2024-11-03T07:40:11.014Z
Learning: In Flow Launcher, when using Windows Forms dialogs (e.g., in `JsonRPCPluginSettings.cs`), path validation is enabled by default in `OpenFileDialog` and `FolderBrowserDialog`, preventing users from selecting invalid paths, but it's possible to opt out of this validation on individual dialogs.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs
📚 Learning: 2025-11-06T12:57:11.574Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 4072
File: Plugins/Flow.Launcher.Plugin.Program/Main.cs:100-111
Timestamp: 2025-11-06T12:57:11.574Z
Learning: In Flow Launcher's Program plugin Main.cs QueryAsync method, the semaphore pattern where WaitAsync(token) is inside a try-catch that only catches OperationCanceledException, followed by an explicit Release() call after the try-catch block, is safe and doesn't cause semaphore leaks. When WaitAsync throws OperationCanceledException, the semaphore is not acquired, so no release is needed. When WaitAsync succeeds, the Release() call after the try-catch executes normally.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs
🧬 Code graph analysis (1)
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs (7)
Plugins/Flow.Launcher.Plugin.Explorer/Settings.cs (2)
Settings(14-240)ActionKeyword(228-239)Flow.Launcher.Plugin/SharedCommands/FilesFolders.cs (1)
IsLocationPathString(246-265)Plugins/Flow.Launcher.Plugin.Explorer/Search/EnvironmentVariables.cs (3)
EnvironmentVariables(10-109)IsEnvironmentVariableSearch(25-31)HasEnvironmentVar(33-41)Plugins/Flow.Launcher.Plugin.Explorer/Search/QuickAccessLinks/QuickAccess.cs (3)
QuickAccess(7-41)List(11-28)List(30-40)Plugins/Flow.Launcher.Plugin.Explorer/Search/WindowsIndex/WindowsIndexSearchManager.cs (7)
IAsyncEnumerable(24-44)IAsyncEnumerable(46-63)IAsyncEnumerable(65-84)IAsyncEnumerable(86-89)IAsyncEnumerable(91-94)IAsyncEnumerable(96-99)IAsyncEnumerable(101-120)Plugins/Flow.Launcher.Plugin.Explorer/Search/Everything/EverythingSearchManager.cs (3)
IAsyncEnumerable(75-90)IAsyncEnumerable(92-126)IAsyncEnumerable(128-145)Plugins/Flow.Launcher.Plugin.Explorer/Search/ResultManager.cs (8)
ResultManager(16-412)Result(62-72)Result(95-173)Result(175-178)Result(180-183)Result(185-227)Result(257-283)Result(285-343)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (5)
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs (5)
1-11: LGTM! Clean imports for the refactored code.The new using statements appropriately support the refactored action keyword logic and helper methods. The static using for Settings enables cleaner enum access.
51-73: LGTM! Action keyword determination is sound.The logic correctly distinguishes path searches from keyword-based searches and appropriately returns empty results when no action keyword matches, preventing the plugin from handling queries it shouldn't.
265-288: LGTM! Clean filtering logic.The
ShouldSkipmethod appropriately centralizes result filtering based on action keywords and file type exclusions. The logic correctly filters folders vs. files for their respective action keywords.
116-123: LGTM! Filtering correctly applied to search results.The
ShouldSkipfiltering is properly integrated into the result processing loop. The null-forgiving operator onactiveActionKeyword!.Valueis safe since line 70 ensures it's non-null at this point.
72-73: LGTM! Modern collection expression syntax.The consistent use of C# collection expressions (
[],[.. results]) throughout the refactored code is idiomatic and improves readability.Also applies to: 90-90, 127-127, 141-142, 146-160
Still getting this for file/folder action keyword. |
Just re-read your description, with regards to this, folder search should not bring up the .txt file in Quick Access unless it's a folder. I don't think there is a need for an option to include/exclude Quick Access items. If file search action keyword-> .txt in Quick Access should be returned. If folder search action keyword -> a folder called txt in Quick Access should be returned. An example use case is if I have a folder 'blah' that is not in the Windows Search index but added to Quick Access, using folder action keyword should still bring up my 'blah' folder. This is so I don't need to rely on the index for getting folders I may need every once in a while. |
|
I also don't think we should list any files or folders if query contains only the file/folder action keywords. In this instance we should just return empty result. |
I agree |
That makes sense. So essentially, Quick Access results should respect the selected filter, right? When using a folder action, only Quick Access items that are folders should be included in the merged results. |
|
I'm working on corrections. |
…removed and search manager refactor to fix the problems reported in PR
…i/Flow.Launcher into feature/new_action_keywords
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
Plugins/Flow.Launcher.Plugin.Explorer/Settings.cs (1)
226-238: Inconsistent null vs. empty dictionary return pattern.The method returns
nullfor empty input (line 229) but returns an emptyDictionarywhen no action keywords match. This inconsistency creates confusion for callers—some must handlenull, while others can safely assume a non-null collection. Consider returning an empty dictionary for all "no match" cases.Apply this diff for consistent API design:
public Dictionary<ActionKeyword, string> GetActiveActionKeywords(string actionKeywordStr) { - var result = new Dictionary<ActionKeyword, string>(); - if (string.IsNullOrEmpty(actionKeywordStr)) return null; + if (string.IsNullOrEmpty(actionKeywordStr)) + return new Dictionary<ActionKeyword, string>(); + + var result = new Dictionary<ActionKeyword, string>(); foreach (var action in Enum.GetValues<ActionKeyword>()) { var keywordStr = GetActionKeyword(action); if (string.IsNullOrEmpty(keywordStr)) continue; var isEnabled = GetActionKeywordEnabled(action); if (keywordStr == actionKeywordStr && isEnabled) result.Add(action, keywordStr); } return result; }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
Plugins/Flow.Launcher.Plugin.Explorer/Languages/en.xaml(1 hunks)Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs(11 hunks)Plugins/Flow.Launcher.Plugin.Explorer/Settings.cs(7 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- Plugins/Flow.Launcher.Plugin.Explorer/Languages/en.xaml
🧰 Additional context used
🧠 Learnings (10)
📚 Learning: 2025-10-16T10:48:30.573Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3854
File: Flow.Launcher/App.xaml.cs:252-275
Timestamp: 2025-10-16T10:48:30.573Z
Learning: In Flow Launcher's App.xaml.cs, the plugin initialization block (lines 252-275) that includes PreStartPluginExecutablePathUpdate, PluginManager.LoadPlugins, PluginManager.InitializePluginsAsync, _mainVM.QueryResults(), and API.SaveAppAllSettings() does not require additional Task.Run wrappers or Dispatcher.InvokeAsync calls according to maintainer Jack251970, as the threading model is already safe as designed.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Settings.csPlugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs
📚 Learning: 2025-07-21T09:19:19.012Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3854
File: Flow.Launcher.Core/Plugin/PluginManager.cs:280-292
Timestamp: 2025-07-21T09:19:19.012Z
Learning: In Flow Launcher's PluginManager.cs, the post-initialization operations (RegisterResultsUpdatedEvent, UpdatePluginMetadataTranslation, RegisterPluginActionKeywords, DialogJump.InitializeDialogJumpPlugin, and AddPluginToLists) are designed to be exception-safe and do not require additional try-catch error handling according to the maintainer Jack251970.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Settings.csPlugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs
📚 Learning: 2025-10-16T09:29:19.653Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3854
File: Flow.Launcher.Core/Plugin/PluginManager.cs:519-523
Timestamp: 2025-10-16T09:29:19.653Z
Learning: In Flow Launcher's PluginManager.cs QueryDialogJumpForPluginAsync method, when a DialogJump plugin is still initializing, returning null is intentional behavior. This allows the query to fall through to the default Explorer plugin, which serves as a fallback handler. This is different from QueryForPluginAsync and QueryHomeForPluginAsync, which show "still initializing" messages because they don't have fallback mechanisms.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Settings.csPlugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs
📚 Learning: 2025-07-21T09:19:49.684Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3854
File: Flow.Launcher/App.xaml.cs:246-262
Timestamp: 2025-07-21T09:19:49.684Z
Learning: In Flow Launcher's App.xaml.cs, the asynchronous plugin initialization task (containing AbstractPluginEnvironment.PreStartPluginExecutablePathUpdate, PluginManager.LoadPlugins, PluginManager.InitializePluginsAsync, and AutoPluginUpdates) does not require additional try-catch error handling according to maintainer Jack251970, as these operations are designed to handle exceptions internally.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Settings.csPlugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs
📚 Learning: 2025-09-04T11:52:29.096Z
Learnt from: jjw24
Repo: Flow-Launcher/Flow.Launcher PR: 3932
File: Flow.Launcher.Core/ExternalPlugins/PluginsManifest.cs:48-55
Timestamp: 2025-09-04T11:52:29.096Z
Learning: In Flow Launcher's PluginsManifest.cs, when dealing with version parsing for the MinimumAppVersion feature, maintainer jjw24 prefers to keep the solution simple rather than implementing comprehensive helper methods for SemVer parsing normalization.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Settings.cs
📚 Learning: 2025-07-06T12:21:37.947Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3572
File: Flow.Launcher/App.xaml.cs:214-216
Timestamp: 2025-07-06T12:21:37.947Z
Learning: In Flow Launcher, the UpdatePluginManifestAsync method in PluginsManifest.cs already has comprehensive internal try-catch handling that logs exceptions and returns false on failure rather than throwing, making external try-catch wrappers unnecessary.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Settings.cs
📚 Learning: 2025-07-01T05:46:13.251Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3791
File: Flow.Launcher.Core/Plugin/PluginManager.cs:293-295
Timestamp: 2025-07-01T05:46:13.251Z
Learning: In Flow.Launcher.Core/Plugin/PluginManager.cs, when checking if a plugin is modified within the PluginManager class itself, prefer using the internal static PluginModified(string id) method directly rather than going through API.PluginModified() for better performance and architectural design.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Settings.cs
📚 Learning: 2025-06-24T19:06:48.344Z
Learnt from: Koisu-unavailable
Repo: Flow-Launcher/Flow.Launcher PR: 3770
File: Flow.Launcher/ViewModel/MainViewModel.cs:0-0
Timestamp: 2025-06-24T19:06:48.344Z
Learning: In Flow.Launcher's Explorer plugin results, the SubTitle property always contains the directory containing the file. For file results, Title contains the filename and SubTitle contains the parent directory. For directory results, SubTitle contains the directory path itself.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Settings.csPlugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs
📚 Learning: 2024-11-03T07:40:11.014Z
Learnt from: Yusyuriv
Repo: Flow-Launcher/Flow.Launcher PR: 3057
File: Flow.Launcher.Core/Plugin/JsonRPCPluginSettings.cs:0-0
Timestamp: 2024-11-03T07:40:11.014Z
Learning: In Flow Launcher, when using Windows Forms dialogs (e.g., in `JsonRPCPluginSettings.cs`), path validation is enabled by default in `OpenFileDialog` and `FolderBrowserDialog`, preventing users from selecting invalid paths, but it's possible to opt out of this validation on individual dialogs.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Settings.csPlugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs
📚 Learning: 2025-11-06T12:57:11.574Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 4072
File: Plugins/Flow.Launcher.Plugin.Program/Main.cs:100-111
Timestamp: 2025-11-06T12:57:11.574Z
Learning: In Flow Launcher's Program plugin Main.cs QueryAsync method, the semaphore pattern where WaitAsync(token) is inside a try-catch that only catches OperationCanceledException, followed by an explicit Release() call after the try-catch block, is safe and doesn't cause semaphore leaks. When WaitAsync throws OperationCanceledException, the semaphore is not acquired, so no release is needed. When WaitAsync succeeds, the Release() call after the try-catch executes normally.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (7)
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs (5)
73-83: Correctly implements empty-query behavior per PR requirements.The logic properly returns all Quick Access items when the query is empty with the QuickAccess keyword active, and returns an empty result list when the query is empty with Folder or File search keywords active, exactly as specified in the PR objectives.
85-92: Path search keyword augmentation aligns with intended behavior.When a path search is detected but neither
PathSearchActionKeywordnorFileSearchActionKeywordis active, the code addsPathSearchActionKeywordto ensure path results are handled. The exclusion ofFileSearchActionKeywordprevents unwanted drive/volume listings when file search is active.
285-294: Filtering logic correctly combines exclusion rules.The method properly checks both excluded file types and action-keyword-based type filtering, returning
trueto skip results that should be excluded.
296-320: Quick Access filtering now respects action keywords.The new implementation addresses the previous review concern by filtering Quick Access results based on the active action keyword using
IsResultTypeFilteredByActionKeyword. For example, whenFolderSearchActionKeywordis active, files are excluded; whenFileSearchActionKeywordis active, folders and volumes are excluded.
132-143: I'll help you verify whether all Quick Access results have SearchResult ContextData. Let me start by examining the codebase to understand the Quick Access result creation and filtering logic.
<function_calls>
#!/bin/bashSearch for Quick Access related code and ContextData assignments
find . -type f -name "*.cs" | grep -i quickaccess | head -20
</function_calls>I need to locate Quick Access related files and examine the SearchManager code. Let me search more broadly:
<function_calls>
#!/bin/bashFind SearchManager.cs and related Quick Access code
fd -e cs | grep -E "(SearchManager|QuickAccess)" | head -20
</function_calls>Let me search for the relevant code patterns:
<function_calls>
#!/bin/bashFind SearchManager.cs file
fd -e cs -p "SearchManager"
</function_calls>Let me try a broader approach:
<function_calls>
#!/bin/bashSearch for GetQuickAccessResultsFilteredByActionKeyword
rg -n "GetQuickAccessResultsFilteredByActionKeyword" --type cs
</function_calls>Let me also search for the filtering pattern mentioned:
<function_calls>
#!/bin/bashSearch for ContextData pattern matching with SearchResult
rg -n "ContextData.*is.*SearchResult" --type cs -C 3
</function_calls>Let me also search for Quick Access result creation:
<function_calls>
#!/bin/bashSearch for QuickAccessLink or similar Quick Access result creation
rg -n "QuickAccessLink|new.*Result" --type cs -g "QuickAccess" -C 2
</function_calls>Let me check the Explorer plugin structure:
<function_calls>
#!/bin/bashList Explorer plugin structure
find . -type d -name "Explorer" 2>/dev/null | head -10
</function_calls>Plugins/Flow.Launcher.Plugin.Explorer/Settings.cs (2)
62-69: New action keyword properties follow established pattern.The
FolderSearchActionKeywordandFileSearchActionKeywordproperties are consistent with existing action keyword properties, defaulting to the global wildcard sign with corresponding enable flags.
167-176: ActionKeyword enum visibility changed to public.The enum is now
public(previouslyinternalper the AI summary) to support the expanded public API surface for folder and file search keywords. The new enum values are properly added.
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs (1)
66-72: Add null check for GetActiveActionKeywords result.
GetActiveActionKeywordsreturnsnullwhen the input string is empty (see Settings.cs line 229:if (string.IsNullOrEmpty(actionKeywordStr)) return null). Line 69 dereferencesactiveActionKeywordswithout checking for null, which will throw aNullReferenceExceptionifGetActiveActionKeywordsreturns null.While line 59 ensures
keywordis never empty by falling back toQuery.GlobalPluginWildcardSign, a defensive null check is essential ifGlobalPluginWildcardSigncould ever be null or empty.Apply this diff to add a defensive null check:
var activeActionKeywords = Settings.GetActiveActionKeywords(keyword); // No action keyword matched - plugin should not handle this query, return empty results. -if (activeActionKeywords.Count == 0) +if (activeActionKeywords is null or { Count: 0 }) { return []; }
🧹 Nitpick comments (2)
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs (2)
6-6: Remove unused import.The
System.Windows.Documentsnamespace is not used anywhere in this file.Apply this diff to remove the unused import:
-using System.Windows.Documents;
117-119: Consider clarifying the "case true or false" pattern.The pattern
case true or falsematches both boolean values and is functionally equivalent to a default case for theisPathSearchboolean. While valid C#, it may confuse readers. Consider usingcase _(discard pattern) or adding a comment to clarify intent.Apply this diff for clarity:
- case true or false + case _ // Match any isPathSearch value for Quick Access when activeActionKeywords.ContainsKey(ActionKeyword.QuickAccessActionKeyword): return QuickAccess.AccessLinkListMatched(query, Settings.QuickAccessLinks);
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs(10 hunks)
🧰 Additional context used
🧠 Learnings (8)
📚 Learning: 2025-07-21T09:19:19.012Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3854
File: Flow.Launcher.Core/Plugin/PluginManager.cs:280-292
Timestamp: 2025-07-21T09:19:19.012Z
Learning: In Flow Launcher's PluginManager.cs, the post-initialization operations (RegisterResultsUpdatedEvent, UpdatePluginMetadataTranslation, RegisterPluginActionKeywords, DialogJump.InitializeDialogJumpPlugin, and AddPluginToLists) are designed to be exception-safe and do not require additional try-catch error handling according to the maintainer Jack251970.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs
📚 Learning: 2025-10-16T09:29:19.653Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3854
File: Flow.Launcher.Core/Plugin/PluginManager.cs:519-523
Timestamp: 2025-10-16T09:29:19.653Z
Learning: In Flow Launcher's PluginManager.cs QueryDialogJumpForPluginAsync method, when a DialogJump plugin is still initializing, returning null is intentional behavior. This allows the query to fall through to the default Explorer plugin, which serves as a fallback handler. This is different from QueryForPluginAsync and QueryHomeForPluginAsync, which show "still initializing" messages because they don't have fallback mechanisms.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs
📚 Learning: 2025-10-16T10:48:30.573Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3854
File: Flow.Launcher/App.xaml.cs:252-275
Timestamp: 2025-10-16T10:48:30.573Z
Learning: In Flow Launcher's App.xaml.cs, the plugin initialization block (lines 252-275) that includes PreStartPluginExecutablePathUpdate, PluginManager.LoadPlugins, PluginManager.InitializePluginsAsync, _mainVM.QueryResults(), and API.SaveAppAllSettings() does not require additional Task.Run wrappers or Dispatcher.InvokeAsync calls according to maintainer Jack251970, as the threading model is already safe as designed.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs
📚 Learning: 2025-07-21T09:19:49.684Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3854
File: Flow.Launcher/App.xaml.cs:246-262
Timestamp: 2025-07-21T09:19:49.684Z
Learning: In Flow Launcher's App.xaml.cs, the asynchronous plugin initialization task (containing AbstractPluginEnvironment.PreStartPluginExecutablePathUpdate, PluginManager.LoadPlugins, PluginManager.InitializePluginsAsync, and AutoPluginUpdates) does not require additional try-catch error handling according to maintainer Jack251970, as these operations are designed to handle exceptions internally.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs
📚 Learning: 2025-06-24T19:06:48.344Z
Learnt from: Koisu-unavailable
Repo: Flow-Launcher/Flow.Launcher PR: 3770
File: Flow.Launcher/ViewModel/MainViewModel.cs:0-0
Timestamp: 2025-06-24T19:06:48.344Z
Learning: In Flow.Launcher's Explorer plugin results, the SubTitle property always contains the directory containing the file. For file results, Title contains the filename and SubTitle contains the parent directory. For directory results, SubTitle contains the directory path itself.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs
📚 Learning: 2024-11-03T07:40:11.014Z
Learnt from: Yusyuriv
Repo: Flow-Launcher/Flow.Launcher PR: 3057
File: Flow.Launcher.Core/Plugin/JsonRPCPluginSettings.cs:0-0
Timestamp: 2024-11-03T07:40:11.014Z
Learning: In Flow Launcher, when using Windows Forms dialogs (e.g., in `JsonRPCPluginSettings.cs`), path validation is enabled by default in `OpenFileDialog` and `FolderBrowserDialog`, preventing users from selecting invalid paths, but it's possible to opt out of this validation on individual dialogs.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs
📚 Learning: 2025-09-04T11:52:29.096Z
Learnt from: jjw24
Repo: Flow-Launcher/Flow.Launcher PR: 3932
File: Flow.Launcher.Core/ExternalPlugins/PluginsManifest.cs:48-55
Timestamp: 2025-09-04T11:52:29.096Z
Learning: In Flow Launcher's PluginsManifest.cs, when dealing with version parsing for the MinimumAppVersion feature, maintainer jjw24 prefers to keep the solution simple rather than implementing comprehensive helper methods for SemVer parsing normalization.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs
📚 Learning: 2025-11-06T12:57:11.574Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 4072
File: Plugins/Flow.Launcher.Plugin.Program/Main.cs:100-111
Timestamp: 2025-11-06T12:57:11.574Z
Learning: In Flow Launcher's Program plugin Main.cs QueryAsync method, the semaphore pattern where WaitAsync(token) is inside a try-catch that only catches OperationCanceledException, followed by an explicit Release() call after the try-catch block, is safe and doesn't cause semaphore leaks. When WaitAsync throws OperationCanceledException, the semaphore is not acquired, so no release is needed. When WaitAsync succeeds, the Release() call after the try-catch executes normally.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs
🧬 Code graph analysis (1)
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs (2)
Plugins/Flow.Launcher.Plugin.Explorer/Settings.cs (2)
Settings(14-239)Dictionary(226-238)Plugins/Flow.Launcher.Plugin.Explorer/Search/QuickAccessLinks/QuickAccess.cs (3)
List(11-28)List(30-40)QuickAccess(7-41)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: gitStream.cm
- GitHub Check: build
🔇 Additional comments (10)
Plugins/Flow.Launcher.Plugin.Explorer/Search/SearchManager.cs (10)
23-27: LGTM!The dictionary mapping is logical and correctly defines which result types to filter for each action keyword. File search excludes folders/volumes, and folder search excludes files.
73-83: LGTM!The empty query handling correctly implements the PR objective: folder/file action keywords with no query text return empty results, while Quick Access shows all links. This prevents unwanted results when only an action keyword is entered.
87-92: LGTM!The conditional augmentation of
PathSearchActionKeywordcorrectly handles the case where a user enters a path query without an explicit path action keyword (e.g., using the wildcard). The exclusion ofFileSearchActionKeywordprevents unwanted drive/volume results during file searches, which aligns with the PR's filtering goals.
132-143: LGTM!The Quick Access result filtering at line 133 properly addresses the previous review concern. By calling
GetQuickAccessResultsFilteredByActionKeyword, Quick Access results now respect the active action keyword filters (e.g., a .txt file won't appear in folder search results). The per-result filtering in the loop ensures search results are also correctly filtered.
164-181: LGTM!The refactoring to collection expression syntax is clean and maintains the same behavior. No functional changes.
183-251: LGTM!The refactoring to collection expressions (
[.. results]) is a clean syntactic modernization with no behavioral changes. The spread operator correctly converts the HashSet to a List.
277-283: LGTM!The updated
Splitcall withStringSplitOptions.RemoveEmptyEntriesis an improvement that handles malformed exclusion lists (e.g., with extra commas) more gracefully.
285-294: LGTM!The method cleanly centralizes result filtering logic, checking both excluded file types and action-keyword-based type filtering. The implementation is straightforward and correct.
296-308: LGTM!This method properly filters Quick Access results to respect the active action keyword. The logic correctly keeps only results whose types are NOT filtered by the action keyword (line 306 negates
IsResultTypeFilteredByActionKeyword), ensuring folder-only or file-only filters work as intended.
309-320: LGTM!The method correctly determines whether a result type should be filtered based on active action keywords. By consulting
_typesToFilterByActionKeyword, it properly implements the file/folder filtering logic central to this PR's feature.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
Plugins/Flow.Launcher.Plugin.Explorer/Settings.cs (1)
226-242: GetActiveActionKeywords implementation is sound; consider avoiding null returnsThe method correctly:
- Ignores keywords that are null/empty.
- Filters by exact match on the provided
actionKeywordStr.- Only includes entries whose enabled flag is true.
- Supports multiple active actions for the same keyword (e.g., wildcard scenarios) via the dictionary.
One minor API suggestion: returning
nullfor an emptyactionKeywordStrcan be slightly awkward for callers compared to always returning a dictionary (possibly empty). Returning the preallocatedresultinstead ofnullwould keep the API non-nullable and reduce the chance of missed null checks, if you don’t rely onnullas a special sentinel elsewhere.Example tweak:
- var result = new Dictionary<ActionKeyword, string>(); - if (string.IsNullOrEmpty(actionKeywordStr)) return null; + var result = new Dictionary<ActionKeyword, string>(); + if (string.IsNullOrEmpty(actionKeywordStr)) return result;
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
Plugins/Flow.Launcher.Plugin.Explorer/Settings.cs(7 hunks)
🧰 Additional context used
🧠 Learnings (9)
📚 Learning: 2025-10-16T10:48:30.573Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3854
File: Flow.Launcher/App.xaml.cs:252-275
Timestamp: 2025-10-16T10:48:30.573Z
Learning: In Flow Launcher's App.xaml.cs, the plugin initialization block (lines 252-275) that includes PreStartPluginExecutablePathUpdate, PluginManager.LoadPlugins, PluginManager.InitializePluginsAsync, _mainVM.QueryResults(), and API.SaveAppAllSettings() does not require additional Task.Run wrappers or Dispatcher.InvokeAsync calls according to maintainer Jack251970, as the threading model is already safe as designed.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Settings.cs
📚 Learning: 2025-07-21T09:19:19.012Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3854
File: Flow.Launcher.Core/Plugin/PluginManager.cs:280-292
Timestamp: 2025-07-21T09:19:19.012Z
Learning: In Flow Launcher's PluginManager.cs, the post-initialization operations (RegisterResultsUpdatedEvent, UpdatePluginMetadataTranslation, RegisterPluginActionKeywords, DialogJump.InitializeDialogJumpPlugin, and AddPluginToLists) are designed to be exception-safe and do not require additional try-catch error handling according to the maintainer Jack251970.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Settings.cs
📚 Learning: 2025-10-16T09:29:19.653Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3854
File: Flow.Launcher.Core/Plugin/PluginManager.cs:519-523
Timestamp: 2025-10-16T09:29:19.653Z
Learning: In Flow Launcher's PluginManager.cs QueryDialogJumpForPluginAsync method, when a DialogJump plugin is still initializing, returning null is intentional behavior. This allows the query to fall through to the default Explorer plugin, which serves as a fallback handler. This is different from QueryForPluginAsync and QueryHomeForPluginAsync, which show "still initializing" messages because they don't have fallback mechanisms.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Settings.cs
📚 Learning: 2025-07-21T09:19:49.684Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3854
File: Flow.Launcher/App.xaml.cs:246-262
Timestamp: 2025-07-21T09:19:49.684Z
Learning: In Flow Launcher's App.xaml.cs, the asynchronous plugin initialization task (containing AbstractPluginEnvironment.PreStartPluginExecutablePathUpdate, PluginManager.LoadPlugins, PluginManager.InitializePluginsAsync, and AutoPluginUpdates) does not require additional try-catch error handling according to maintainer Jack251970, as these operations are designed to handle exceptions internally.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Settings.cs
📚 Learning: 2025-09-04T11:52:29.096Z
Learnt from: jjw24
Repo: Flow-Launcher/Flow.Launcher PR: 3932
File: Flow.Launcher.Core/ExternalPlugins/PluginsManifest.cs:48-55
Timestamp: 2025-09-04T11:52:29.096Z
Learning: In Flow Launcher's PluginsManifest.cs, when dealing with version parsing for the MinimumAppVersion feature, maintainer jjw24 prefers to keep the solution simple rather than implementing comprehensive helper methods for SemVer parsing normalization.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Settings.cs
📚 Learning: 2025-07-06T12:21:37.947Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3572
File: Flow.Launcher/App.xaml.cs:214-216
Timestamp: 2025-07-06T12:21:37.947Z
Learning: In Flow Launcher, the UpdatePluginManifestAsync method in PluginsManifest.cs already has comprehensive internal try-catch handling that logs exceptions and returns false on failure rather than throwing, making external try-catch wrappers unnecessary.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Settings.cs
📚 Learning: 2025-07-01T05:46:13.251Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3791
File: Flow.Launcher.Core/Plugin/PluginManager.cs:293-295
Timestamp: 2025-07-01T05:46:13.251Z
Learning: In Flow.Launcher.Core/Plugin/PluginManager.cs, when checking if a plugin is modified within the PluginManager class itself, prefer using the internal static PluginModified(string id) method directly rather than going through API.PluginModified() for better performance and architectural design.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Settings.cs
📚 Learning: 2025-06-24T19:06:48.344Z
Learnt from: Koisu-unavailable
Repo: Flow-Launcher/Flow.Launcher PR: 3770
File: Flow.Launcher/ViewModel/MainViewModel.cs:0-0
Timestamp: 2025-06-24T19:06:48.344Z
Learning: In Flow.Launcher's Explorer plugin results, the SubTitle property always contains the directory containing the file. For file results, Title contains the filename and SubTitle contains the parent directory. For directory results, SubTitle contains the directory path itself.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Settings.cs
📚 Learning: 2024-11-03T07:40:11.014Z
Learnt from: Yusyuriv
Repo: Flow-Launcher/Flow.Launcher PR: 3057
File: Flow.Launcher.Core/Plugin/JsonRPCPluginSettings.cs:0-0
Timestamp: 2024-11-03T07:40:11.014Z
Learning: In Flow Launcher, when using Windows Forms dialogs (e.g., in `JsonRPCPluginSettings.cs`), path validation is enabled by default in `OpenFileDialog` and `FolderBrowserDialog`, preventing users from selecting invalid paths, but it's possible to opt out of this validation on individual dialogs.
Applied to files:
Plugins/Flow.Launcher.Plugin.Explorer/Settings.cs
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (6)
- GitHub Check: gitStream.cm
- GitHub Check: gitStream.cm
- GitHub Check: gitStream.cm
- GitHub Check: gitStream.cm
- GitHub Check: gitStream.cm
- GitHub Check: build
🔇 Additional comments (3)
Plugins/Flow.Launcher.Plugin.Explorer/Settings.cs (3)
1-11: Imports for new search managers look correctThe added
usingdirectives for the Explorer search managers and providers are coherent with the types referenced later in the file; no issues here.
62-69: New folder/file keyword settings align with existing pattern
FolderSearchActionKeyword/FileSearchActionKeywordand their...Enabledflags follow the same pattern as Path/Index/QuickAccess keywords (defaulting toGlobalPluginWildcardSignwith disabled flags). This keeps configuration behavior consistent and avoids accidentally enabling new behaviors by default.
167-224: Enum and switch extensions are consistent and exhaustiveExtending
ActionKeywordwithFolderSearchActionKeywordandFileSearchActionKeywordand wiring them through all four helpers (GetActionKeyword,SetActionKeyword,GetActionKeywordEnabled,SetActionKeywordEnabled) keeps the enum and switch expressions in sync; there are no missing cases, and error paths remain unchanged.
…i/Flow.Launcher into feature/new_action_keywords
|
@jjw24 Can you test again? Thanks! |
3 participants
CHANGES
Details
Note
The Search Manager in Explorer was refactored to simplify the addition of new action keywords.
Previously, each new keyword required code changes in multiple places.
Now, the logic for action keywords and filters is much easier to understand and extend.
The quick access results is filtered action keyword based